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Abstract 

As originally proposed, type classes provide overloading and ad- 
hoc definition, but can still be understood (and implemented) in 
terms of strictly parametric calculi. This is not true of subsequent 
extensions of type classes. Functional dependencies and equality 
constraints allow the satisfiability of predicates to refine typing; this 
means that the interpretations of equivalent qualified types may not 
be interconvertible. Overlapping instances and instance chains al- 
low predicates to be satisfied without determining the implemen- 
tations of their associated class methods, introducing truly non- 
parametric behavior. We propose a new approach to the semantics 
of type classes, interpreting polymorphic expressions by the be- 
havior of each of their ground instances, but without requiring that 
those behaviors be parametrically determined. We argue that this 
approach both matches the intuitive meanings of qualified types 
and accurately models the behavior of programs. 

Categories and Subject Descriptors D.3.1 [Programming Lan- 
guages]: Formal Definitions and Theory — Semantics; F.3.2 [Log- 
ics and Meanings of Programs]: Semantics of Programming Lan- 
guages — Denotational semantics 

Keywords overloading; type classes; semantics 

1. Introduction 

Implicit polymorphism (as provided by the Hindley-Milner type 
systems in ML and Haskell) provides a balance between the safety 
guarantees provided by strong typing, and the convenience of 
generic programming. The Hindley-Milner type system is strong 
enough to guarantee that the evaluation of well-typed terms will 
not get stuck, while polymorphism and principal types allow pro- 
grammers to reuse code and omit excessive type annotation. Type 
classes [16] play a similar role for overloading: they preserve strong 
typing (ruling out run-time failures from the use of overloaded 
symbols in undefined ways) without requiring that programmers 
explicitly disambiguate overloaded expressions. Since their intro- 
duction, type classes have seen numerous extensions, such as multi- 
parameter type classes, functional dependencies [5], and overlap- 
ping instances [13]; a variety of practical uses, from simple over- 
loading to capturing complex invariants and type-directed behav- 
ior; and, the adoption of similar approaches in other strongly-typed 
programming languages, including Isabelle and Coq. 
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1.1 Dictionary-Passing and its Disadvantages 

The semantics of type classes has primarily been given by trans- 
lations from instance declarations and (implicit) overloading to 
dictionaries and (explicit) dictionary arguments. This parallels the 
treatment of implicit polymorphism by translation to systems with 
explicit polymorphism (such as System F), and shares similar chal- 
lenges. For a simple example, in Haskell, the map function has the 
polymorphic type scheme (f — > w) — > [t] — > [u] . In translating to 
System F, this could be interpreted as either 

\/t.\/u.(t — > u) — ► [t] — > [u] or V«.Vr.(r — > m) — > [t] — > [«]. 

But these types are not equivalent: they express different orders 
of passing type arguments. There are various ways of addressing 
this discrepancy: for example, Mitchell [8] shows that, for any two 
translations of an implicitly typed scheme, there is a term (which he 
calls a retyping function) which transforms terms of one translation 
to terms of the other, while only manipulating type abstractions and 
applications. Similar issues arise in the semantics of type classes. 
For example, a function to compare pairs (r, u) for equality could 
be given either the type scheme 

(Eq t, Eq u) => (t, u) — > (t, u) — > Bool 

or the type scheme 

(Eq u, Eq t) => (f, u) — > (t, u) — > Bool. 

In a dictionary-passing translation, type classes are interpreted by 
tuples, called dictionaries, containing the type-specific implemen- 
tations of each of the class methods. Class instances correspond to 
dictionary definitions, while predicates in types correspond to dic- 
tionary arguments. In the case of the Eq class, which has equality 
and inequality methods, we could define Eq dictionaries by 

EqDict t = (t — > t — > Bool, Bool). 

Even though the two types for pair equality above are equivalent in 
the implicitly overloaded setting, their dictionary-passing transla- 
tions are not: the first corresponds to a function of type 

EqDict / — > EqDict u — > (f, u) — > it, u) — > Bool, 

while the second corresponds to 

EqDict u — > EqDict t — > (f, u) — > (t, u) — > Bool, 

Again, approaches exist to address this discrepancy: for exam- 
ple, Jones shows [3] that there are conversion functions, similar 
to Mitchell's retyping functions, to convert between different trans- 
lations of the same overloaded term. 

Our own work began by exploring instance chains [10], a pro- 
posed extension to Haskell-like type class systems. In the course 
of this exploration, we discovered several difficulties with existing 
approaches to the semantics of overloading. 

Mismatch in expressivity. System F typing is significantly more 
expressive than the Hindley-Milner type systems it is used to 
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model. In particular, even within the translation of an ML or 
Haskell type scheme, there are arbitrarily many expressions that 
do not correspond to any expressions of the source language. 
The problem is compounded when considering dictionary-passing 
translations of type classes. For example, there is no notion in 
Haskell of class instances depending on terms; on the other hand, 
there is no difficulty in defining a term of type Int — > EqDict Int. 
Uses of such a term cannot be equivalent to any use of the methods 
of Eq. As a consequence, there are properties of source programs 
(for example, that any two instances of = at the same type are 
equal) that may not be provable of their dictionary-passing transla- 
tion without reference to the specific mechanisms of translation. 

Predicates refine typing. Second, the notions of equivalence of 
System F and Haskell types diverge once the satisfiability of pred- 
icates can refine typing. For example, functional dependencies al- 
low programmers to declare that some parameters of a class depend 
upon others; in the declaration 

class Elems c e | c — ¥ e where 
empty : : c 

insert : : e — ¥ c — ¥ c 

the dependency c — ¥ e captures the intuition that the type of a 
container's elements are determined by the type of the container. 
Concretely, given two predicates Elems r v and Elems r' v', if we 
know that r = r', then we can conclude v = v' . This property 
is lost in the dictionary-passing translation. Dictionaries for Elems 
contain just their methods: 

ElemsDict ce = (c, e — ¥ c — ¥ c) 

As a consequence, there are types that are equivalent in Haskell, 
but are not interconvertible in the dictionary-passing interpretation. 
For example, the type (Elems ce, Elems ce') =>• e — ¥ e' — ¥ c is 
equivalent to the (simpler) type (Elems ce) => e — ¥ e — ¥ c as 
we must have that e — e' for the qualifiers in the first type to be 
satisfiable. However, there is no corresponding bijection between 
terms of type ElemsDict ce — ¥ ElemsDict c e — > e — ¥ e — ¥ c 
and terms of type ElemsDict ce — ¥ e — ¥ e — ¥ c. While we can 
construct a term of the second type given a term of the first, there 
is no parametric construction of a term of the first type from a term 
of the second. 

Non-parametric behavior. Finally, other extensions to class sys- 
tems make it possible to define terms which have no translation 
to parametric calculi. For example, we could define a function 
invBool that negated booleans and was the identity on all other 
types. We begin by introducing a suitable class: 

class Univ t where 
invBool : : t — ¥ t 

There are several approaches to populating the class, using differ- 
ent extensions of the Haskell class system. Using overlapping in- 
stances [13], we could simply provide the two desired instances of 
the class, relying on the type checker to disambiguate them based 
on their specificity: 

instance Univ Bool where 

invBool = not 
instance Univ t where 

invBool = id 

Using instance chains, we would specify the ordering directly: 

instance Univ Bool where 

invBool = not 
else Univ t where 

invBool = id 



With either of these approaches, we might expect that the type of 
the class method invBool is (Univ t) => t — ¥ t. However, the 
predicate Univ r is provable for arbitrary types r. Thus, the above 
type is intuitively equivalent to the unqualified type t — ¥ t; however, 
there is no term of that type in a purely parametric calculus that has 
the behavior of method invBool. (In practice, this is avoided by 
requiring that invBool's type still include the Univ predicate, even 
though it is satisfied in all possible instantiations; while this avoids 
the difficulties in representing invBool in a parametric calculus, it 
disconnects the meaning of qualified types from the satisfiability of 
their predicates.) 

1.2 Specialization-based Semantics 

We propose an alternative approach to the semantics of type-class 
based implicit overloading. Rather than interpret polymorphic ex- 
pressions by terms in a calculus with higher-order polymorphism, 
we will interpret them as type-indexed collections of (the inter- 
pretations of) monomorphic terms, one for each possible ground 
instantiation of their type. We call this a specialization-based ap- 
proach, as it relates polymorphic terms to each of their (ground- 
typed) specializations. We believe this approach has a number of 
advantages. 

• First, our approach interprets predicates directly as restrictions 
of the instantiation of type variables, rather than through an in- 
termediate translation. Consequently, properties of the source 
language type system — such as the type refinement induced by 
the Elems predicates — are immediately reflected in the seman- 
tics, without requiring the introduction of coercions. 

• Second, our approach naturally supports non-parametric exam- 
ples, such as class Univ, and avoids introducing artificial dis- 
tinction between the semantics of expressions using parametric 
and ad-hoc polymorphism. 

• Third, because our approach does not need to encode overload- 
ing via dictionaries, it becomes possible to reason about class 
methods directly, rather than through reasoning about the col- 
lection of dictionaries defined in a program. 

Our approach builds on Ohori's simple semantics for ML polymor- 
phism [12], extended by Harrison to support polymorphic recur- 
sion [1]. 

In this paper, we introduce a simple overloaded language called 
H~ (§2), and give typing and equality judgments in the presence of 
classes and class methods. We apply our specialization-based ap- 
proach to give a denotational semantics of H~ (§3), and show the 
soundness of typing and equality with respect to the denotational 
semantics (§4). We also develop two examples, to demonstrate the 
advantages of our approach. First, we consider a pair of definitions, 
one parametric and the other ad-hoc, defining operational equiva- 
lent terms. We show that the defined terms are related by our equal- 
ity judgment (§2.3) and have the same denotations (§3.5). This 
demonstrates the flexibility of our approach, and the ability to rea- 
son about class methods directly (the second and third advantages 
listed above). Second, we extend H~ with functional dependen- 
cies (§5), and establish the soundness of the (extended) typing and 
equality judgments, all without having to augment the models of 
terms. This demonstrates the extensibility of our approach, and the 
close connection between properties of source terms and properties 
of their denotations (the first advantage listed above). 

2. The H Language 

Figure 1 gives the types and terms of H~ ; we write x to denote a 
(possibly empty) sequence of x's, and if 7r is a predicate C r, we 
will sometimes write class(ir) for C. As in Jones's theory of qual- 
ified types [2], the typical Hindley-Milner types are extended with 
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Figure 1: Types and terms of H 



qualified types p, capturing the use of predicates. We must also ac- 
count for the definition of classes and their methods. One approach 
would be to expand the grammar of expressions to include class 
and instance declarations; such an approach is taken in Wadler and 
Blott's original presentation [16]. However, this approach makes 
such definitions local, in contrast to the global nature of subsequent 
type class systems (such as that of Haskell), and introduces prob- 
lems with principal typing (as Wadler and Blott indicate in their 
discussion). We take an alternative approach, introducing new top 
level constructs (axioms A, method signatures Si, and method im- 
plementations lm) to model class and instance declarations. We re- 
fer to tuples of top level information as class contexts and will 
give versions of both our typing and semantic judgments parame- 
terized by such class contexts. Note that this leaves implicit many 
syntactic restrictions that would be present in a full language, such 
as the requirement that each instance declaration provide a com- 
plete set of method implementations. 

2.1 H Typing 

We begin with the typing of H~ expressions; our expression lan- 
guage differs from Jones's only in the introduction of p (providing 
recursion) . Typing judgments take the form 

P | T hi M : a, 

where P is a set of predicates restricting the type variables in T and 
a, and A is the set of class axioms (the latter is the only significant 
difference between our type system and Jones's). The typing rules 
for H~ expressions are given in Figure 2. We write ftv(r) for the 
free type variables in r, and extend ftv to predicates n, contexts P, 
and environments T in the expected fashion. Rules (=> I) and 
(=> E) describe the interaction between the predicate context P and 
qualified types p. Otherwise, the rules are minimally changed from 
the corresponding typing rules of most Hindley-Milner systems. 

We continue with the rules for predicate entailment in H~, 
given in Figure 3. The judgment d : P \\~a 7T denotes that the 
axiom named d proves predicate tv, given assumptions P and class 
axioms A. We use a dummy instance name, written -, in the case 
that the goal is one of the assumptions. We will omit the instance 
name if (as in the typing rules) the particular instance used is 
irrelevant. We write P Ih Q if there are di ...d„ such that dt : P lh 
Qi, and \\~a P to abbreviate 0 I hi P. Our entailment relation differs 
from Jones's entailment relation for type classes and from our 
prior systems [10] in two respects. First, our system is intentionally 
simplified (for example, we omit superclasses and instance chains). 
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Figure 2: Expression typing rules of H~ 
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Figure 3: Predicate entailment rules of H . 

Second, we do not attempt to capture all the information that would 
be necessary for an dictionary-passing translation; we will show 
that having just the first instance name is sufficient to determine the 
meanings of overloaded expressions. 

In the source code of a Haskell program, type class methods are 
specified in class and instance declarations, such as the following: 

class Eq t where (=) : : t — > t — > Bool 
instance Eq t => Eq [t] where xs = ys = ... 

We partition the information in the class and instance declarations 
into class context tuples (A, Si, lm). The logical content is captured 
by the axioms A; in this example, we would expect that there would 
be some instance name d such that 

(d:Wt. Eqt => Eq [t]) G A. 

Haskell's concrete syntax does not name instances; for our pur- 
poses, we assume that suitable identifiers are generated automati- 
cally. The method signatures are captured in the mapping Si; we 
distinguish the class in which the method is defined (along with the 
corresponding type variables) from the remainder of the method's 
type scheme. For this example, we would have 

Si(=) = (Eq t, t -¥ t -¥ Bool). 

Note that we have not quantified over the variables appearing in the 
class predicate, nor included the class predicate in the type scheme 
Bool. Each predicate in the range of Si will be of the form 
C 1 for some class C and type variables f, as they arise from class 
definitions. The type scheme of a class member may quantify over 
variables or include predicates beyond those used in the class itself. 
For example, the Monad class has the following definition: 
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Figure 5: Equality for H terms. 
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Figure 4: H typing with class contexts. 



class Monad m where 
return : : a — > m a 
(»=) ::ma->(a->mb)->mb 

Note that the variable a in the type of return is not part of the 
Monad constraint. Thus, we would have that 

Si(return) = (Monad m,\fa.a — S- ma) . 

The method implementations themselves are recorded in compo- 
nent Im, which maps pairs of method and instance names to imple- 
menting expressions. 

To describe the typing of methods and method implementations, 
we begin by describing the type of each method implementation. 
This is a combination of the defining instance, including its context, 
and the definition of the method itself. For example, in the instance 
above, the body of the = method should compare lists of arbitrary 
type t for equality (this arises from the instance predicate Eq [t] 
and the signature of =), given the assumption Eq t (arising from 
the defining instance). That is, we would expect it to have the type 

V?.Eq t=>[t]-¥ [t] — > Bool. 

We introduce abbreviations for the type scheme of each method, 
in general and at each instance, assuming some class context 
(A,Si,Im). For each method name x such that Si(x) = (ir,Vu.p), 
we define the type scheme for x by: 

<J X — Vf.V«. 7T => p, 

or, equivalently, writing p as Q => r: 

a x = Vf, u. (tt, Q) => r 

where, in each case, t — ftv(ir). Similarly, for each method x as 
above, and each instance d such that 

• (x, d) G dom(/ra); 

• (d:Vi.P=> tt') G A; and, 

• there is some substitution 5 such that Sty = tt' 
we define the type scheme for x in d by: 

a x , d =Vi,u. {P,SQ)^St. 

Finally, we give a typing rule parameterized by class contexts 
in Figure 4; in x,- : a Xi , the x, range over all methods defined in the 
program (i.e., over the domain of Si). Intuitively, an expression M 
has type r under (A, Si, Im) if: 

• None of the class instances overlap. More expressive class sys- 
tems will require more elaborate restrictions; we give an ex- 
ample when extending H~ to support functional dependen- 
cies (§5). 

• Each method implementation Im(x, d) has the type a X; d (meth- 
ods are allowed to be mutually recursive). 

• The main expression has the declared type a, given that each 
class method x, has type a Xj . 



2.2 Equality of H Terms 

In this section, we give an axiomatic presentation of equality for 
H~ terms. Our primary concerns are the treatment of polymor- 
phism and class methods; otherwise, HP differs little from standard 
functional calculi. As described in the introduction, our intention is 
to permit reasoning about class methods directly, without relying 
on either a dictionary-passing translation or a preliminary inlining 
step that resolves all method overloading. This results in two un- 
usual aspects of our rules: 

• While our presentation gives equality for expressions, it relies 
critically on components of the class context (A,Si,Im) — the 
axioms A to determine which instance solves given constraints, 
and the method implementations Im to determine the behavior 
of methods. 

• The treatment of polymorphism cannot be completely paramet- 
ric, and different equalities may be provable for the same term 
at different types; for example, we cannot hope to have uniform 
proofs of properties of the = method when it is defined differ- 
ently at different types. 

Equality judgments take the form P | V M = N : a, denot- 
ing that, assuming predicates P, variables typed as in T, and class 
context \&, expressions M and N are equal at type a. To simplify 
the presentation, we have omitted equational assumptions; how- 
ever, extending our system with assumptions and a correspond- 
ing axiom rule would be trivial. The rules are those listed in Fig- 
ure 5, together with rules for reflexivity, symmetry, and transitivity 
of equality, and the expected a-equivalence and congruence rules 
for each syntactic form. Rules {/?}, {??}, {p} and {Let} should 
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be unsurprising. Rules {=>I} and {=>E} mirror the corresponding 
typing rules, assuring that we can only conclude equalities about 
well-typed expressions. Rule {VE} should also be unsurprising: if 
we have proved that two expressions are equal at a quantified type, 
we have that they are equal at any of its instances. Rule {VI} is 
less typical, as it requires one subproof for each possible ground 
type (GType ranges over ground type expressions). Note that this 
is only non-trivial for terms involving overloading. Finally, rule 
{Method} provides (one step of) method resolution. Intuitively, 
it says that for some class method x at type a, if instance d proves 
that x is defined at a, then x is equal to the implementation of x 
provided by instance d. 

2.3 Polymorphic Identity Functions 

In the introduction, we gave an example of a polymorphic function 
(invBool) that could be instantiated at all types, yet did not have 
parametric behavior. In this section, we will consider a function 
which does have parametric behavior, but is defined in an ad-hoc 
fashion. We will demonstrate that our treatment of equality allows 
us to conclude that it is equal to its parametric equivalent. 

Our particular example is the identity function. First, we give its 
typical definition: 

idl : : t -»• t 
idl x = x 

For our second approach, we intend an overloaded definition that is 
provably equal to the parametric definition. We could produce such 
a definition using instance chains: 



Id2' (t -> u) where 



class Id2' t where 

id2' : : t -»• t 
instance (Id2' t, Id2' u) 

id2' f = id2' of o id2' 
else Id2' t where 

id2' x = x 



This gives an ad-hoc definition of the identity function, defined 
at all types but defined differently for function and non-function 
types. Reasoning about this definition would require extending 
the entailment relation to instance chains, introducing significant 
additional complexity. We present simpler instances, but restrict the 
domain of types to achieve a similar result. 

class Id2 t where 

id2 : : t -J- t 
instance Id2 Int where 

id2 x = x 
instance (Id2 t, Id2 u) 

id2 f = id2 o f o id2 



Id2 (t -¥ u) where 



We will use Int to stand in for all base (non-function) types. 

It should be intuitive that, while they are defined differently, 
idl x and id2 x should each evaluate to x for any integer or 
function on integers x. Correspondingly, given a class context ^ 
that describes (at least) Id2, we can prove that idl = id2 : 
r (we omit the empty context and empty assumptions) for any 
such type r. The case for integers is direct: one application of 
{Method} is sufficient to prove id2 = Xx.x : Int — > Int. 
For functions of (functions of . . . ) integers, the proof has more 
steps, but is no more complicated. For the simplest example, to 
show that 

id2 = Xx.x : (Int -S- Int) -»■ (Int -> Int), 
we use {Method} to show 

id2 = A/.(id2 o/o id2) : (Int -> Int) -> (Int -> Int). 



Relying on the usual definition of composition and {/?}, we show 

h* A/.(id2 of o id2) ee A/.Ax.id2(/"(id2jc)) : 

(Int -> Int) -> (Int -»■ Int) 

Finally, by two uses of {Method} for id2 on integers, and {77}, 
we have 

h* A/.Ax.id2(y(id2x)) = Xf.f : (Int -> Int) -> (Int -> Int) 

and thus the desired result. 

We cannot expect to prove that idl = id2 at all types (i.e., 
idl ee id2 : Vt.t — > t) without limiting the domain of types. 
For example, there is no instance of Id2 at type Bool; therefore, we 
cannot prove any non-trivial equalities id2 = M : Bool — > 
Bool. However, if we were to restrict the grammar of types to 
those types for which Id2 is defined (that is, if we define that 
r ::= Int | t — >■ t), then we could construct such an argument. To 
show that id2 ee Xx.x : Vf.f — > t, we begin by applying {VE}, 
requiring a derivation id2 ee Xx.x : r — > r for each ground 
type t. We could construct such a set of derivations by induction 
on the structure of types, using the argument for Int above as the 
base case, and a construction following the one for Int — > Int for 
the inductive case. 

A similar approach applies to the formulation using instance 
chains (class Id2 ' ): we could show that the first clause applied to 
functions, the second clause applied to any non-function type, and 
use induction over the structure of types with those cases. 

3. A Simple Semantics for Overloading 

Next, we develop a simple denotational semantics of H~ programs, 
extending an approach originally proposed by Ohori [12] to de- 
scribe the implicit polymorphism of ML. As with the presentation 
of equality in the previous section, the primary new challenges arise 
from the definition of class methods and the treatment of overload- 
ing. We will demonstrate that the specialization-based approach is 
well-suited to addressing both challenges. In particular, it allows 
expressions to have different interpretations at each ground type 
without introducing additional arguments or otherwise distinguish- 
ing qualified from unqualified type schemes. 

3.1 The Meaning of Qualified Types 

To describe the meaning of overloaded expressions, we must begin 
with the meaning of qualified types. Intuitively, qualifiers in types 
can be viewed as predicates in set comprehensions — that is, a class 
Eq denotes a set of types, and the qualified type V?.Eq t => t — > 
t — > Bool describes the set of types {t — > t — > Bool | t G Eq}. 
However, most existing approaches to the semantics of overloading 
do not interpret qualifiers in this fashion: Wadler and Blott [16], 
for instance, translate qualifiers into dictionary arguments, while 
Jones [2] translates qualified types into a calculus with explicit 
evidence abstraction and application. 

Our approach, by contrast, preserves the intuitive notion of 
qualifiers. Given some class context >J/ = (A,Si,Im), we define 
the ground instances [a\ * of an H _ type scheme a by: 

ItJ» = {t} 



[ty => p\ q, 



[pj* if Ir-A 7T 
0 otherwise 



LVr.aJ*= |J [[r/t]a} 9 . 

rGGType 

Equivalently, if we define GSubstQ) to be substitutions that map t 
to ground types and are otherwise the identity, we have 

[Vt.P => rj* = {St I 5 G GSubst(i, \\- A SP}. 
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We will omit annotation when it is unambiguous. 

In the typing judgments for H~, predicates can appear in both 
types and contexts. To account for both sources of predicates, we 
adopt Jones's constrained type schemes (P \ a), where P is a list 
of predicates and a is an H~ type scheme; an unconstrained type 
scheme a can be treated as the constrained scheme (0 | a) (as an 
empty set of predicates places no restrictions on the instantiation 
of the variables in a). We can define the ground instances of 
constrained type schemes by a straightforward extension of the 
definition for unconstrained schemes: if ^ = (A, Si, Im), then 

L(P | \Tt.Q =3> r)J* = {St \ S G GSubst{t),\\- A (P,SQ)}. 
3.2 Type Frames for Polymorphism 

We intend to give a semantics for H~ expressions by giving a map- 
ping from their typing derivations to type-indexed collections of 
monomorphic behavior. We begin by fixing a suitable domain for 
the monomorphic behaviors. Ohori assumed an underlying type- 
frame semantics; his translations, then, were from implicitly poly- 
morphic terms to the interpretations of terms in the simply-typed 
A-calculus. Unfortunately, we cannot apply his approach without 
some extension, as type classes are sufficient to encode polymor- 
phic recursion. However, we can adopt Harrison's extension [1] of 
Ohori's approach, originally proposed to capture polymorphic re- 
cursion, and thus also sufficient for type class methods. 

We begin by defining PCPO frames, an extension of the stan- 
dard notion of type frames. A PCPO frame is a tuple 

t = cr ype h , r erm h , t t , v , c r , u T , ± T > , 

(where we will omit the type and term annotations when they are 
apparent from context) subject to the following six conditions. 

1 . For each ground type r, 7~~ type [r] is a non-empty set providing 
the interpretation of r. 

2. For each typing derivation A of T h M : r and T-compatible 
environment 77, 7^ erm [A] 77 is the interpretation of M in 7^ ype [t] . 

3. T T , V : T type ir -S- uj x 7^ ype |[r] provides the 
interpretation of the application of an element of r — > v to an 
element of r. 

4. For any/,g G 7^ ype |[r vj, if, for all x G 7^ ype |[r], 
T T ,v(f,x) = T T>v (g,x), then/ = g. 

5. T term [[-] and T TiV respect the semantics of the simply-typed A- 
calculus. In particular: 

• If A derives T h x : r, then T[A]r? = r\(x); 

• If A derives F h MN : v, A M derives F h M : 
t — > v and Ajv derives F h N : r, then T|[A]r; = 
r T ^(T[AMlr?,T[Aj V lr ? );and, 

• If Aa derives T h Ax : r.M : t — > v and A M derives T, x : 
t \~ M : v, then T T , V (TIA X } V , d) = T[Am](??[x ^ d]). 

6. Each set T[r] is a PCPO with respect to C T , U T and _L T . 

The first five conditions are the standard requirements for type 
frames; the final condition relates the type frame and PCPO struc- 
tures of a PCPO frame. Given a PCPO frame T, we can define 
the interpretation of a polymorphic type scheme a as the mappings 
from the ground instances r of a to elements of T[t]. That is: 

r chem >]* = n(r g ^j*).-r ype H. 

where we will omit the scheme and * annotations when it is not 
ambiguous. For example, the identity function Xx.x has the type 
scheme Vf J — > t. Therefore, the semantics of the identity function 
is a map from the ground instances of its type (i.e., the types 
r — > t) to the semantics of the simply-typed identity function at 



each type. We would expect its semantics to include the pair 

(Int -¥ Int,T term [[l- Ax : Int.x : Int -> lnt\) 

to account for the Int — > Int ground instance of its type scheme, 
the pair 

(Bool -> Bool,T term |[l- Ax : Bool.x : Bool -> Bool]} 

to account for the Bool — > Bool ground instance of its type scheme, 
and so forth. Note that if a has no quantifiers, and so [a\ * = {r} 
for some type r, then we have 

T cheme H* = {{(r,fe)}|foGT type H}, 

and so an element of T scheme |[r] is a singleton map, not an element 
of T* ype [r]. Harrison proves that T[cr] is itself a pointed CPO, 
justifying solving recursive equations in T[cr] . 

Theorem 1 (Harrison). Let T be a PCPO frame. Then, for any 
type scheme a, T\cf\ is a pointed CPO where: 

• For any f, g G 7>J, / E<r g (Vt G [oJ-/(t) 

g(r)); 

' The bottom element _L CT is defined to be {(r, _L T ) r G [o\ }; 
and, 

• The least upper bound of an ascending chain {/J} C T\cr\ is 
{{t,u t ) t G Ya\,u T = U T (fi(r))}. 

We can define continuous functions and least fixed points for sets 
T[cr] in the usual fashion: 

• A function/ : Tfoj -> T{cr'\ is continuous if/(U CT A' i ) = 
LV (f(Xi)) for all directed chains X t in T{a\. 

• The fixed point of a continuous function/ : T\cr\ — > T[c] 
is defined by fix(/) = U CT (/"(_L CT )), and is the least value such 
thatfix(f)=/(fix(/)). 

3.3 Semantics for Overloaded Expressions 

We can now give denotations for (typing derivations of) H~ ex- 
pressions. For some type environment T and substitution S G 
GSubst(frv(T)), we define an S — T-environment r\ as a mapping 
from variables to values such that r\(x) G 7~[(S<t)] for each as- 
signment (x : <r) in T. Given a PCPO frame T, a derivation A of 
P I T \- A M : a, a ground substitution S, and an environment r\, we 
define the interpretation TJAJSt; by cases. We have included only 
a few, representative cases here. 

• Case (— ¥E): we have a derivation of the form 



Ax =- 



P I T K M : t -»• t' 



At = - 



P \ T \~a N : t 



P\F\- A (MN) : t' 
Let v — Sr and v' = St', and define 

T[A]Sr7 = {(^^((TIArJSryXw v'), 

(T[A 2 ]S77)( W ))». 

Case (=>I): we have a derivation of the form 



Ai 



P,-k \ Y \~a M : p 
P I T \- A M : 7T => L 



This rule excludes those cases in which the predicate does not 
hold; thus, we define: 



T[A]5r? = 



fr[Ai]577 ifSPIhSTr; 
I 0 otherwise. 
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• Case (=>E): we have a derivation of the form 

Al =-; 1 

P\T\- A M : tt ^ p P lh 7T 
P | T I-a M : p 

This rule does not affect the semantics of expression M, and so 
we define: 

T\A}S n = TIAipTj. 

• Case (VI): we have a derivation of the form 

Ai = '- 

P|rh A M:cr (0>(P,r) 

P | T I-a M : Vf.cr 

Intuitively, we interpret a polymorphic expression as the map 
from ground instances of its type to its interpretations at those 
types. As the interpretation of the subderivation Ai is already in 
the form of a such a map, we can interpret A as the union of the 
meanings of Ai for each ground instantiation of the quantified 
variable t. Formally, we define 

TlA}Sr,= U TIArl^^r])^. 

r £ GType 

• Case (VE): we have a derivation of the form 

Al =-T- i 

P \ T \~a M : Vf.CT 

~ P | T h A M : [r/t]a 

By definition, [Vf.aJ = UreGJjj* L[ r A]°"J - and so ll T ^ 
[Vf.crJ . Thus, the interpretation of A is a subset of the interpre- 
tation of Ai; writing /| r for the restriction of a function / to 
some subset Y of its domain, we define: 

T[A]5 ?7 = (r[A 1 ]Sr ? )| L[T/(]CT j. 
3.4 Expressions with Class Contexts 

To complete our semantics of H~ programs, we must account for 
the meaning of class methods. Our approach is intuitively simple: 
we collect the meanings of the class methods from the method 
implementations in each instance, and use the meanings of the 
methods to define the meaning of the main expression. Formally, 
we extend the interpretation function from derivations of P r h A 
M : a to derivations of P | F h* M : a as follows: 

• Let A be a derivation of P | T h* M : t. Then we know that A 
must begin with an application of (Ctxt) (Figure 4) with one 
subderivation 



P | F,Xi : a Xi I-a Im(y,d) : cr y ,d 
for each pair (y, d) G dom(/m) and a subderivation 

A M = 

Pj r,xfTa^\- A M : r 

for the main expression M. We enumerate the methods in the 
program as x\ , X2, ■ ■ ■ , x m , and let 

S = TKIxTK] x-xTk], 



For each method %u we define a function f, ■ : E — > TJoit,], 
approximating its meaning, as follows: 

M(b 1 ,b 2 ,...,b,„))S V = U TlA Xh 4S( V {x]^bj}), 

and define function/ : E — > S, approximating the meaning of 
all the methods in the program, as 

f(b) = {fi(b),f2(b),...,f m (b))- 

We can now define a tuple b, such that the component bi is the 
meaning of method x,, as follows: 

Finally, we extend the interpretation function to programs by 
TIApr, = riA„]5(r,[x7 ^~b~]). 

3.5 Polymorphic Identity Functions Revisited 

We return to our earlier example of polymorphic identity func- 
tions (§2.3). As before, we consider two definitions of identity 
functions, one given parametrically (idl) and one given by over- 
loading (id2). In this section, we will show that the denotations of 
idl and id2 agree at all types for which id2 is defined. By doing 
so, we provide an intuitive demonstration that our denotational se- 
mantics captures the meaning of ad-hoc polymorphic and agrees 
with our definition of equality for H~ terms. 

We show that TJidl] and T*[id2] have the same value at each 
point in the domain of T*[id2] ; that is, that for any type r € GType 
such that lh Id2 r, 

T[id1](r^r) = T[id2](r^T). 

We proceed by induction on the structure of r. In the base case, 
we know that r = K for some non-functional type K. As we have 
assumed lh Id2 r, we must have that K — Int, and, from the 
instances for Id2, we have 

T[id2j(£ -*•«■)= T[id2j(Int -> Int) 

= T[h Ax : Int.x : Int -> Int]. 

As T[id1](Int -> Int) = T[h Ax : Int.x : Int -> Int], we 
have TJidl] (A" K) = T[id2](A —J- K). In the inductive case, 
we know that r = To — > Ti for some types to and n. From the 
assumption that lh Id2 (r () — > n) and the instances for Id2, we 
can assume that Id2 To, Id2 n, and that 

T[id2](T -»• t) = T[h A/ : (t 0 -> n).Mo/oJV: t -»■ t] 

for some simply typed expressions M and N such that T[M] = 
T[id2](T 0 -> to) and T[iV] = T[id2](Ti -> n). The induction 
hypothesis gives that T[id2] (to -> To) = T[id1](T 0 -»■ To) 
and that T[id2](ri -¥ n) = TJidl ](n -> n), and thus that 
TJM] = TJh Ax : tlx : n -J- n] and TJA'] = TJh Ax : r 0 .x : 
to — > To]. By congruence, we have 

TJid2](T -J- t) = TJA/ : (t 0 -J- n).(Ax : T!.x)o/o(Ax : t 0 .x)]. 

Finally, assuming a standard definition of composition, and reduc- 
ing, we have 

TJid2](T t) = TJA/ : (to -»■ ti)./] 
= TJA/ : r.f] 

= TJid1](T^T). 

In our previous discussion of this example, we argued that if 
the set of types were restricted to those types for which Id2 held, 
then idl and id2 were equal. We can show a similar result here, 
by showing that if we define that t ::= Int | r — ► r, then 
TJidl ] = TJid2] . We begin by showing that they are defined over 
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the same domain; that is, that [Vr. t — > t\ — LVw.Id2 u => u — > u\ . 
By definition, we have 

|Vt t -> t\ = {r -> r | r G GType} 

and 

[Vw. Id2 u => U -> wj = {r -> r | r G Grype, lh Id2 r}. 

We show that lh Id2 r for all types r by induction on the structure 
of r. In the base case, we know that r = Int, and by the first 
instance of Id2 we have lh Id2 r. In the inductive case, we know 
that t = To — > T\ for some types 7ft, Ti. In this case, we have 
that [to/J, ti/m]t = f — > u and by the induction hypothesis, that 
lh Id2 ro and lh Id2 n. Thus, from the second instance of Id2, we 
can conclude that lh Id2 (r„ — ¥ ri), that is, that lh Id2 r. Because 
lh Id2 r for all ground types r, we have 

{r -> r | r G GType, lh Id2 r} = {r -> r \ r G GFype}, 

and so T[id1] and T[id2] are defined over the same domain. We 
have already shown that 7~[id1] and T[[id2] agree at all points at 
which they are defined, and so we conclude 7~[id1] — 7~[id2]. 

4. Formal Properties 

The previous sections have outlined typing and equality judgments 
for H terms, and proposed a denotational semantics for H~ typ- 
ings. In this section, we will relate these two views of the language. 
We begin by showing that the denotation of a typing judgment falls 
into the expected type. This is mostly unsurprising; the only un- 
usual aspect of H~ in this respect is the role of the class context. We 
go on to show that the equational judgments are sound; again, the 
unusual aspect is to do with polymorphism ({VI} and {VE}) and 
class methods ({Method}). The H~ type system follows Jones's 
original formulation of OML; we rely on several of his metafheo- 
retical results, such as the closure of typing under substitution. 

Theorem 2 (Soundness of typing). Given a class context ;/ A 
is a derivation of P \ F h* M : o, S is a substitution, and r) is an 
(ST)-environment, then T[A]S?7 G Tf(SP \ So)} 9 . 

We will divide the proof into three pieces. First, we show the 
soundness of the judgment P | F \~a M : a. Then, we will argue 
that the union of the implementations of a method has the type of 
the method itself. Finally, we can combine these results to argue the 
soundness of P \ F h* M : o. 

Lemma 3. Given a class context — (A,Si,Im) where A is 
non-overlapping, if A ls- a derivation of P \ F \~a M : o, S 
is a substitution, and r\ is a (ST)- environment, then TJA]5r; G 
Tl(SP\Sa)h. 

Proof. The proof is by induction over the structure of derivation 
A. The cases are straightforward; we include several representa- 
tive examples. (Meta-variables A„ are as in the definition of T[-] 
above.) 

• Case (=> I). Observe that [{S(P,tt) \ Sp)\ = [{SP S (rr => 
p) )\ . As such, if 

T[Ai]S?7 G T[(5 (P, 7r) I S»]*, 

then we must also have that 

TlAjS V eTl(SP\S(ir^ p))h. 

• Case (=> E). As entailment is (trivially) closed under substitu- 
tion, P lh 7r implies that SP lh Sir for any substitution 5; thus, 
we can conclude that [(S P | S (ty p))J = [(S P \ Sp)\. 
Finally, assuming that T[Ai]5»? G T\{SP \ S (tt => p))J, we 
can conclude that T f A] S-q G T{ (S P \ S p) ] . 



• Case (VI). Because o — Vf.cr', we have that 

W= U L[rA]«r'J, 

rGGType 

and thus that 

th= u (Tlir/tWi). 

r^GType 

Thus, assuming that for ground types r, T[Ai](5[f <-¥ r])rj G 
T\{SP | Sa')}, we have 

TlA]S V e( (J Tl(SP\So')j\ =Tl(SP\Sa)j. 

\TeGType J 

• Case (VE). Assuming that r[Ai]5rj G T\(SP \ 5(Vf.cr'))], 
the same argument about ground types as in the previous case 
gives that71A]S?7 G T{{S P \ So)}. □ 

The interpretation of typings P \ F h* M : o depends on 
the interpretations of the class methods. We will begin by showing 
that the interpretation of each method is in the denotation of its 
type. To do so, we will demonstrate that the interpretation of the 
type scheme of a method is the union of the interpretation of the 
type schemes of its instances. This will show that the union of 
the implementations is in the type of the method, from which the 
desired result follows immediately. 

Lemma 4. The ground instances of the type scheme of a method x 
are the union of its ground instances at each of its instances. That 
is, 

|0*| = |J \o- x j\ . 

(x,d) Gdom(/m) 

Proof. Let o x = Vt.(n, Q) => r, where x is a method of class(n). 
We prove that 

M = |J [<Tx,d\ 

(d,A-)edom(/m) 

by the inclusions 

L<*jc U L<*,«J. 

(A,rf)edom(/m) 

and 

k.J2 U L^J- 

(x,d)edom(Im) 

We will show only the first inclusion; the second is by an identical 
argument. Fix some v G Yo x \ . By definition, there is some 5 G 
GSubstQ) such that v — St and lh Sir,SQ. Because lh S-7T, 
there must be some (d : Vm. P => 7r') G A and substitution 
S' G GSubst{u) such that Sn = S' n' and lh 5' P. Now, we have 
that a x ,d = Vt' .(P, T Q) => T r for some substitution T; thus, there 
is some T' G GSubst(t') such that v = T' {Tt), SP = T' (TQ), 
and so v G [o x ,d\ ■ □ 

Lemma 5. The interpretation of the type scheme of a method x is 
the union of the interpretations of its type scheme at each instance. 
That is, 

T\o x } = |J T\o x ,4. 

(x,d)edom(Im) 

Proof. Recall that 

r heme W = n(re [o x \).r ype lT}. 



114 



From Lemma 4, we have that 

T chem >J = n ( r g |J k^J j •T type H. 

\ (i,i)6dom(/m) / 

As 7^ ype [ - ] is a function, this is equivalent to 

(i,rf)£dom(to) 

and finally, again from the definition of T eheme [-], 

r chem >j = |j r cheme Kj. □ 

(A,d)edom(;m) 

Proof of Theorem 2. Finally, we can extend the soundness of our 
semantics to include class contexts. From Lemmas 4 and 5, we 
know that the interpretations of the methods fall in the interpreta- 
tions of their type schemes, and so if r\ is a 5 — T-environment, then 
7] ^xl i — ^ bi\ is a S — (r, x, : o Xj ) -environment. From Theorem 3, we 
have that TlA M }S(r][xJ i-> fc) G T[(5P | 5a)]*, and thus that 
TlA}S V €Tl(SP\Scr)}*. □ 

We would like to know that the meaning of an expression is 
independent of the particular choice of typing derivation. Unfortu- 
nately, this is not true in general for systems with type classes. A 
typical example involves the read and show methods, which have 
the following type signatures 

read : : Read t => String — > t 
show : : Show t => t — > String 

We can construct an expression showo read of type 

(Read t, Show t) => String — > String, 

where variable t can be instantiated arbitrarily in the typing, chang- 
ing the meaning of the expression. To avoid this problem, we adopt 
the notion of an unambiguous type scheme from Jones's work on 
coherence for qualified types [3]. 

Definition 6. A type scheme o = Vt.P => r is unambiguous if 

ftv{P)<Zftv{r). 

As long as we restrict our attention to unambiguous type schemes, 
we have the expected coherence result. For example, suppose that 
A is a derivation of P \ F \~a Xx.M : a. We observe that A must 
conclude with an application of (— say at Pq | F \- a Xx.M : 
t — > t', followed by a series of applications of (=>I), (=>E), (VI) 
and (VE). While these latter applications determine a, we can see 
intuitively that each v G [o\ must be a substitution instance of 
t — > t', and that the interpretation of A at each ground type must 
be the interpretation of an instance of the subderivation ending with 
(— >I). We can formalize these two observations by the following 
lemma. 

Lemma 7. If a — Vt.Q => r, and Ai . . . A„ is a sequence of 
derivations such that: 

• Ai is a derivation of Pi \ F \~a M : n; 
' A n is a derivation of P j F \~a M : a; 

• Each ofA 2 . . . A n is by (=tf ), (=>E), (VI) or (VE); and, 

• Each A, is the principal subderivation of Aj+i 

then 

(a) There is a substitution S such thatr — Sti and PL) Q Hh SP\; 
and, 

(b) For all ground substitutions S, for all v G L^°"J> there is a 
unique S' such that T[ A„] Sr)v = T[Ai]5'»ju. 



The proof is by induction on n; the cases are all trivial. We can now 
characterize the relationship between different typings of M. 

Theorem 8 (Coherence of T[-J). If A derives P \ T h A M : 
a and A' derives P' \ T' \~a M : a', where a and a' are 
unambiguous, then for all substitutions S and S' such that SP Hh 
S' P',ST — S' r', and Sa — S'a', and for all ground substitutions 
U,TlAj(U°S)=TlA'j(U°S'). 

The proof is by induction over the structure of M. In each case, 
use of the inductive hypothesis is justified by Lemma 7(a), and the 
conclusion derived from the definition of T[-] and Lemma 7(b). 
As an immediate corollary, we have that if A and A' are two 
derivations of the same typing judgment, then T|A] = T[A']. 
We can also show that, if P j T \- A M : a is a principal typing of 
M, with derivation A, and A' derives P \ F \- A M : a' for any other 
o 1 ', then for each substitution 5' there is a unique 5 such that, for all 
environments r\, T\A\Sr) D T[A']SV 

Theorem 9 (Soundness of =). Given a class context if a is 
unambiguous, P \ F M = N : a, and Am, An are derivations 
ofP | T M : a,P | T N : a, then T[A M J = T[Aat]. 

Proof. The proof is by induction over the derivation of P \ F 
M = N : g. The interesting cases are to do with polymorphism and 
overloading. 

• Case {=> I}. We have a derivation concluding 

P, 7T | T M = N : p 

P\F\-^M = N: n^p 

Let Am, Ajv be typing derivations of P | F \~a M : 7r => p 
and P | r \~a N : it => p; without loss of generality 
(because of Theorem 8), assume that each is by (=>I), with 
subderivations A' M , A' N of P, it \ F M : p and P, n 
F N : p. From the definition of T[-], we have TJAm] = 
TJA M ] and T|Ajv] = TJA^] . The induction hypothesis gives 
that T|A M ] = TJAjv], and so we can conclude T[A M J = 

nA N j. 

• Case {=> E}. We have a derivation concluding 

P\F\- 9 M = N:tt^p PU-ait 

P | T h* M = N : p 

where <J/ = (A,Si,Im). As in the previous case, the interpre- 
tation of the typing derivations for P \ F M : p and 
P | rh*M:7r=>pare equal, and similarly for the typing 
derivations for N, and thus the induction hypothesis is sufficient 
for the desired conclusion. 

• Case {VI}. We have a derivation concluding 

{(P | T M = N : [r/t]a) \ t G GType} 
P | T M = N : Vr.o- 

From the induction hypothesis, we can conclude that, given 
derivations A T M of P \ F h* M : [r/t]a and A^ of P F 
N : [r/t]a, TIA T M \ = T\A N \. Let A M derive P \ F Hp M : 
V/.a (and, without loss of generality, assume A M is by (VI)); 
we know that T[A M ] = Ureor^ TlA M ].We argue similarly 
for derivations Ajv of P \ F N : Vf.cr, and conclude that 
T[A M ] =TfA N l 

• Case {VE}. We have a derivation concluding 

P | T M = N : Vr.cr 
P | T M = N : [r/t]a 
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Let A M , A N be derivations that M and N have type [r /t] a ; with- 
out loss of generality, assume they are by (VE), with subderiva- 
tions A' M , A' N that M and N have type W.cr. From the induction 
hypothesis, we know T[A M ] = T[A^], and from the defini- 
tion of T[-] we know that T[A M ] C T[A M ] and TJAjy] C 
T[A#]. Thus, we can conclude that T[A M ] = T[Ajv]. 

• Case {Method}. We have a derivation of the form 

Si(x) = u,a d:P\\- A STY 
P I T l-<A,5i,/m) * = Im(x,d) : So- 
Let A M be the derivation of P | F x : S a. From the defini- 
tion of T[-J, we know that T[Am]S»? = T[IA M ]S(?7[x7 1-> fc]) 
where the x, are the class methods, the £>, are their imple- 
mentations, and A' M is the derivation of P \ F,x t : a, \- A 
x : Sa. Since x is a class method, we know that ??[x7 i-> £>,] 
maps x to some method implementation fcj, and therefore that 
T|A M ] C bj. We also know that bj is the fixed point of a func- 
tion fj((bi, b n ))S V = {J d TlA X:d ,}S(r][xi i y bi]), where 
A Vjrf ' derives P | T b /m(x, d') : cr*^/ and d is one of the du 
Thus, we know that if A N derives P \ F /m(x, d) : Sa, then 
T[Ajv] C ft,-. Finally, as T[A M J and TJAjv] are defined over 
the same domain, we have that T[Am] = TJAjv]. □ 

5. Improvement and Functional Dependencies 

In the introduction, we set out several ways in which extensions 
of type class systems went beyond the expressiveness of exist- 
ing semantic approaches to overloading. In this section, we re- 
turn to one of those examples, demonstrating the flexibility of our 
specialization-based approach to type-class semantics. 

Functional dependencies [5] are a widely-used extension of type 
classes which capture relationships among parameters in multi- 
parameter type classes. Earlier, we gave a class Elems to abstract 
over common operations on collections: 

class Elems c e | c — > e where 
empty : : c 

insert : : e — > c — > c 

The functional dependency c — > e indicates that the type of a 
collection (c) determines the type of its elements (e). Practically 
speaking, this has two consequences: 

• A program is only valid if the instances in the program respect 
the declared functional dependencies. For example, if a pro- 
gram already contained an instance which interpreted lists as 
collections: 

instance Elems [t] t where . . . 

the programmer could not later add an instance that interpreted 
strings (lists of characters in Haskell) as collections of code- 
points (for simplicity represented as integers): 

instance Elems [Char] Int 

• Given two predicates Elems r v and Elems r' v', if we know 
t — t', then we must have v = v' for both predicates to be 
satisfiable. 

We now consider an extension of H~ to support functional de- 
pendencies. Following Jones [4], we introduce a syntactic char- 
acterization of improving substitutions, one way of describing 
predicate-induced type equivalence. We then extend the typing and 
equality judgments to take account of improving substitutions. Fi- 
nally, we show that the extended systems are sound with respect to 
our semantics. Importantly, we do not have to extend the models of 



terms, nor do we introduce coercions, or other intermediate trans- 
lations. We need only show that our characterization of improving 
substitutions is sound to show that the resulting type equivalences 
hold in the semantics. 

5.1 Extending H with Functional Dependencies 

To account for the satisfiability of predicates in qualified types, 
Jones introduces the notion of an improving substitution 5 for a set 
of predicates P [4]. Intuitively, a 5 improves P if every satisfiable 
ground instance of P is also a ground instance of SP. Jones uses 
improving substitutions to refine the results of type inference while 
still inferring principal types. We will adopt a similar approach, but 
in typing instead of type inference. 

Syntax. We begin by extending the syntax of class axioms to 
include functional dependency assertions: 

Index sets X, Y C N 

Class axioms a ::= C : X ~* Y \ d : Vf. P => ty 

In the representation of functional dependency axioms, we treat the 
class parameters by index rather than by name. If A were the axioms 
for the example above, we would expect to have a dependency 

Elems : {0} ~» {1} G A. 

Any particular class name may appear in many functional depen- 
dency assertions, or in none at all. We adopt some notational ab- 
breviations: if X is an index set, we write it =x it' to indicate that 
7r and 7r' agree at least on those parameters with indices in X, and 

similarly write ty ~x it' to indicate that 5 is a unifier for those 
parameters of n and n' with indices in X. 

Improvement. To account for improvement in typing, we need a 
syntactic characterization of improving substitutions. In the case of 
functional dependencies, this can be given quite directly. We can 
give an improvement rule as a direct translation of the intuitive 
description above: 

P\\-Ct P\\-Cv 

(C : X ~* Y) € A T =x v r ~y v 

(FUNDEP) 

A h S improves P 

For example, if we have some Q such that Q lh Elems r v and Q lh 
Elems tv', then (FUNDEP) says that the any unifying substitution 
U such that U v = U v' is an improving substitution for Q. If S 
is an improving substitution for P, then the qualified type schemes 
(P | a) and (SP \ Sa) are equivalent, and we should be able 
to replace one with the other at will in typing derivations. One 
direction is already possible: if a term has type a, then it is always 
possible to use it with type 5 a (by a suitable series of applications 
of (VI) and (VE)). On the other hand, there is not (in general) a 
way with our existing typing rules to use a term of type 5 a as a 
term of type a. We add a typing rule to support this case. 

SP | SF \- A M : Sa A h S improves/ 5 

(IMPR) 

P | T h A M : a 

As in the case of (=>I) and (=>E), (IMPR) has no effect on the 
semantics of terms. Thus, if we have a derivation 

Al = 7 1 

SP | SF hi M : Sa A h 5 improves P 

~ P | T \- A M : a 

we define that T[A]S'?7 = T[Ai]S"r?, where 5" o 5 = S' (the 
existence of such an 5" is guaranteed by the soundness of (FUN- 
DEP)). Finally, we add a rule to the equality judgment allowing us 
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to use improving substitutions in equality proofs. 

5 P | S r h <A ,a-» Af = N : S a A h S improves P 

{Impr} — 

P I r h {AiSiM) M = N : a 

Validating Functional Dependency Axioms. We must augment 
the context rule to check that the axioms respect the declared de- 
pendencies. This can be accomplished by, first, refining the overlap 
check to assure that no axioms overlap on the determining param- 
eters of a functional dependencies, and second, requiring that, for 
each dependency C : X Y and each instance P => n of class 
C, any variables in the positions Y are determined by the functional 
dependencies of P. Our formalization of the latter notion follows 
Jones's development [6]. We define the closure of a set of variables 
J with respect to the functional dependencies F as the least set j£ 
such that 

• 7 C /+; and 

• If U ~» V G F and U C J+, then V C /+. 

We write fh>x(C r) to abbreviate LLgx-ZM 7 *)' define the instantia- 
tion of a functional dependency assertion C : X ~* Y at a predicate 
7t = C t, as the dependency ftvx{n) ~* ftvy (7r) , and write (A , P) 
for the set of the instantiation of each functional dependency asser- 
tion in A at each predicate in P. We can now define the verification 
conditions for axioms and the new version of (Ctxt), as follows. 

{tt oo x tt' I [d : P => tt), (d' : P' => it'), (class(ir) : X ~» Y) G A] 
h non-overlapping(A) 

{ftv(7r r ) Cftv{*x)+ (AtP) \(d:P=>*), {class(n) : X ^ Y) e A} 
h covering(A) 

h non-overlapping (A) h covering(A) 
{(P | r,x,- : <r Vf hi Im(y,d) : a y , d ) \ (y,d) G dom(/m)} 
P | T,x i Ta^ i h A M : a 

(Ctxt) 

P I r ^ {A ,si,im) M : a 

5.2 Soundness 

The significant challenge in proving soundness of the extended 
rules is showing that when A h 5 improves P is derivable, 5 is 
an improving substitution for P. Once we have established that 
result, the remaining soundness results will be direct. We introduce 
notation for the satisfiable ground instances of predicates P: 

[P\a = {SP | 5 G GSubst(ftv{P)), lh SP}. 

We can now formally describe an improving substitution. 

Lemma 10. Given a set of axioms A such that h non-overlapping (A) 
and\- covering(A), if A h SimprovesP, then [P\ A — [SP\ A . 

Proof. By contradiction. Assume that A h 5 improves P; then we 
must have no, 7Ti such that I hi 7To, I hi Ti and there is a functional 
dependency (class(-K) : X ~» Y) G A such that 7To =x 7Ti 
but 7ro y^y 7Ti. We proceed by induction on the heights of the 
derivations of lh 7To, I hi tti. 

• There are distinct axioms : P => 7r ( ', , d' : P' => 7r^ G A and 
substitutions So, Si such that So7T 0 = no and Si 7rJ = 7rJ. 
But then So o Si is a unifier for n' u ~x n[, contradicting 
h non-overlapping(A). 

• There is a single axiom d : P tt' 0 and substitutions So, Si 
such that So tv'o = and Si ir' 0 = iri . We identify two sub- 
cases. 



■ There is some type variable in/rvy(7r 0 ) \ftvx(Tr'o) that is not 
constrained by P. This contradicts h covering(A). 

■ There is some n' G P such that So tt' and Si n' violate 
a functional dependency of class(ji'). The derivations of 
lh So tt' and lh Si 7r' must be shorter than the derivations of 
lh 7T 0 , lh 7Ti, and so we have the desired result by induction. 

□ 

Theorem 11 (Soundness of typing). Given a class context if A 
is a derivation of P | T h^ M : a, S is a substitution, and r) is an 
(Sr)-environment, then Tf A] Sr] G 7~[(SP | So")]*. 

Proof. We need only consider the (IMPR) case. From Lemma 10, 
we have that if T improves P, then T{{P \ <r)]* = T[(PP | 
Per)]]*, and so the result follows from the induction hypothesis. 

□ 

We extend our notion of ambiguity to take account of functional 
dependencies: it is enough for the variables in the predicates P to 
be determined by the variables of r. 

Definition 12. A type scheme a = Vf.P => r is unambiguous 
(given class axioms A) if/fv(P) Cftv(T)^, A p y 

The previous definition of ambiguity is a special case of this defi- 
nition, where fd(A, P) is always empty. As uses of (IMPR) do not 
affect the semantics of terms, its introduction does not compromise 
coherence. 

Theorem 13. If a is unambiguous and Ai, A2 are derivations of 
P I T h* M : a, then T[Ai] = T[A 2 J. 

Theorem 14 (Soundness of =). Given a class context >J/, (/ a is 
unambiguous, P \ F \-y M = N : a, and Am, Aw are derivations 
ofP I T h* M : g,P I T h* N : a, then T[A M J* = T[Ajv]*. 

Proof. Again, we need consider only the {Impr} case. Without 
loss of generality, assume A M and A N are by (IMPR), with sub- 
derivations A' M and A' N . As the interpretations of A M and A N are 
equal to the interpretations of A' M and A^, the result follows from 
the induction hypothesis. □ 

6. Related Work 

The semantics of polymorphism, in its various forms, has been 
studied extensively over the past half century; however, the par- 
ticular extensions of Haskell that motivated this work are recent, 
and have received little formal attention. 

Our approach was inspired by Ohori's semantics of Core 
ML [12]. While Ohori's approach describes the semantics of poly- 
morphism, he does not represent polymorphic values directly, 
which leads to an unusual treatment of the typing of let expres- 
sions. Harrison extends Ohori's approach to treat polymorphic re- 
cursion [1]; in doing so, he provides a representation of polymor- 
phic values. Harrison suggests that his approach could be applied 
to type classes as well. 

Ohori's approach to the semantics of ML is somewhat unusual; 
more typical approaches include those of Milner [7] and Mitchell 
and Harper [9]. Ohori identifies reasons to prefer his approach 
over either that of Milner or that of Mitchell and Harper: both ap- 
proaches use a semantic domain with far more values than corre- 
spond to values of ML, either because (in the untyped case) those 
values would not be well-typed, or (in the explicit typed case) they 
differ only in the type-level operations. 

The semantics of type-class-based overloading has also received 
significant attention. Wadler and Blott [16] described the mean- 
ing of type classes using a dictionary-passing translation, in which 
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overloaded expressions are parameterized by type-specific imple- 
mentations of class methods. Applying their approach to the full 
Haskell language, however, requires a target language with more 
complex types than their source language. For example, in trans- 
lating the Monad class from the Haskell prelude, the dictionary 
for Monad r must contain polymorphic values for the return and 
(»=) methods. 

In his system of qualified types [2], Jones generalized the treat- 
ment of evidence by translating from a language with overloading 
(OML) to a language with explicit evidence abstraction and appli- 
cation. Jones does not provide a semantics of the language with 
explicit evidence abstraction and application; indeed, such a se- 
mantics could not usefully be defined without choosing a particular 
form of predicate, and thus a particular form of evidence. 

Odersky, Wadler and Wehr [11] propose an alternative formu- 
lation of overloading, including a type system and type inference 
algorithm, and a ideal-based semantics of qualified types. How- 
ever, their approach requires a substantial restriction to the types of 
overloaded values which rules out many functions in the Haskell 
prelude as well as the examples from our previous work [10]. 

Jones [5] introduced functional dependencies in type classes, 
and discusses their use to improve type inference; his presentation 
of improvement is similar to ours, but he does not augment typ- 
ing as does our (IMPR) rule. Sulzmann et al. [15] give an alterna- 
tive approach to the interaction of functional dependencies and type 
inference, via a translation into constraint-handling rules; unfortu- 
nately, their presentation conflates properties of their translation, 
such as termination, with properties of the relations themselves. 
System Fc [14] extends System F with type-level equality con- 
straints and corresponding coercion terms. While we are not aware 
of any formal presentation of functional dependencies in terms of 
System Fc, we believe that a formulation of our (FUNDEP) rule 
in terms of equality constraints is possible. In contrast to our ap- 
proach, System Fc requires extending the domain of the semantics, 
while still requiring translation of source-level features (functional 
dependencies or GADTs) into features of the semantics (equality 
constraints). 

7. Conclusion 

We have proposed an alternative approach to the semantics of 
overloading, based on interpreting polymorphic values as sets of 
their monomorphic interpretations, which avoids several problems 
with traditional translation-based approaches. We have applied this 
result to a simple overloaded calculus, and shown the soundness 
of its typing and equality judgments. Finally, we have argued that 
the approach is flexible enough to support extensions to the type 
system, such as allowing the use of improving substitutions in 
typing. We conclude by identifying directions for future work: 

• Practical class systems are richer than the one used in this 
paper. We would like to extend these results to fuller systems, 
including our prior work on instance chains. 

• Dictionary-passing provides both a semantics of overloading 
and an implementation technique. We would like to explore 
whether implementation techniques based on specialization can 
be used to compile practical languages. 

• We claim that our approach avoids making distinctions between 
some observationally equivalent terms (such as in the poly- 
morphic identity function example). We would like to explore 
whether adequacy and full abstraction results for the underlying 
frame model can be extended to similar results for our seman- 
tics. 

• Our definition of equality provides jy-equivalence; however, r\ 
equivalence is not sound for Haskell. We would like to explore 



either whether our approach can be adapted to a language with- 
out ^-equivalence. 
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